With this feature enabled, the kernel code size increases by ~37kB. That's not very much, even on a Pi Zero, but given that it is opt-in - both by the system as a whole and by each application - it will probably only be used by a small fraction of users, so the costs have to be scaled up accordingly.

Hi @pelwell,
Thank you for your feedback and for looking into this.
I understand the principle of keeping the kernel as lean as possible, and the ~37kB increase for an opt-in feature is a valid point of discussion.
However, I would respectfully argue that framing this as a feature for a "small fraction" of users might not fully capture the breadth and history of this request. The demand for KSM support is a long-standing issue within the community, with discussions on this very topic dating back nearly a decade to 2015 (as seen in issue #1238 ). For almost ten years, users have been hoping for a native solution.
This functionality is critical for a growing number of users running memory-intensive workloads, from monitoring tools like Netdata to multiple containerized services. For these applications, there are no effective workarounds.
More importantly, KSM would be a game-changer for extending the viability of older Raspberry Pi models. For devices with limited RAM, it can significantly prolong their useful lifespan and unlock new potential for applications that are currently memory-prohibitive. This directly supports the sustainability and maximum utilization of the hardware many users already own.
The one-time cost of 37kB, especially for an opt-in feature that has zero impact on those who don't enable it, seems a very reasonable trade-off for the substantial and continuous memory savings it offers to those who need it.
Given the nearly decade-long history of this community request, its implementation would be a truly welcome and significant step forward. It would demonstrate a powerful commitment to maximizing the potential and longevity of all Raspberry Pi hardware, empowering users to do more with their devices, both new and old.
I sincerely hope this can be reconsidered.

Note: As English is not my first language, I've used AI assistance to help refine my points and ensure they are conveyed with clarity.

demand for KSM support is a long-standing issue within the community

"long-standing" is not the same as "widespread"..

How would the average home user be able to benefit from KSM? This is a genuine question, not rhetorical.

demand for KSM support is a long-standing issue within the community对 KSM 支持的需求是社区中一个长期存在的问题

"long-standing" is not the same as "widespread"..“长期存在”并不等同于“广泛存在”..

How would the average home user be able to benefit from KSM? This is a genuine question, not rhetorical.普通家庭用户如何从 KSM 中受益？这是一个真诚的问题，而不是修辞。

Wow... This is a good question.
The key benefit for the average home user lies in reducing the impact of planned obsolescence. Older Raspberry Pi models often face limitations due to insufficient memory, leading to their premature phasing out. By enabling KSM—an optional feature—users can significantly reduce memory consumption by merging identical memory pages, thus extending the useful lifespan of their devices.
Since this feature is entirely opt-in, it imposes no additional burden on users who do not require it. However, those who enable it can achieve substantial memory savings, resulting in smoother performance and delaying hardware replacement.
In short, this optional setting provides users greater flexibility and helps maximize the value and longevity of their existing Raspberry Pi hardware.
For example, I have a Raspberry Pi Zero 2 W with only 512MB of RAM at one of the home that I seldom go there :(. For me, enabling this feature is crucial for reducing RAM usage, allowing me to run more services efficiently. Although optional for higher-memory devices like my Raspberry Pi 5B, it remains significantly beneficial for lower-memory models like the Zero 2 W. :)
Thank you again for your thoughtful engagement on this topic.

Hi pelwell,
Thank you for the genuine question. You're right to ask how this benefits the average user, and not just assume it's a feature for experts.
Let's consider the natural evolution of any curious user on a Raspberry Pi. They begin with a single script or application. Soon, their ambition grows. They want to run a few things at once: perhaps a small web server for a personal project, a script that interacts with it, and maybe a simple database. Or they start to explore modern tools by running a couple of lightweight containerized services.
This is a very common "next step" in anyone's learning journey. And it's precisely here, on a Pi Zero or an older Pi 3, that they hit an invisible wall. The system becomes sluggish or unstable, not because of a bug in their code, but because they've exhausted the most precious resource: RAM. Each of those processes, however small, loads its own copy of shared libraries.
KSM acts as an invisible enabler in exactly this scenario. It isn't a feature they need to "use," but a property of the system that makes it more resilient. For the tiny, one-time investment of ~37kB of kernel space, it reclaims a far more valuable resource, allowing their multi-part project to simply work. It turns a moment of frustration that might end their journey into a successful learning experience.
This touches on a fundamental question of platform philosophy. As newer, more powerful hardware becomes available, there's a choice to be made. Do we design a system that subtly nudges users towards a hardware upgrade as their ambitions grow? Or do we build a system that celebrates resourcefulness, equipping the hardware they already own to grow with them?
There's a powerful magic in maximizing the potential of what you have. It feels deeply aligned with the Raspberry Pi's original spirit. A feature like KSM is a testament to that principle. It's a small, elegant piece of engineering that honors the constraints of the most affordable devices in the family.
This is why nethershaw's point from the original discussion remains so resonant: adoption follows availability. By including this, we aren't just serving a vocal minority. We are investing in the potential of countless future users, creating a more capable platform where ambition isn't immediately gated by memory. It's a small change that reaffirms a powerful, original commitment: to empower anyone to do more with less.

Note: As English is not my first language, I've used AI assistance to help refine my points and ensure they are conveyed with clarity.

That's a lot of pretty words, but they don't really address my question so I'll spell it out more clearly.

The description of the CONFIG_KSM option says:

Enable Kernel Samepage Merging: KSM periodically scans those areas
          of an application's address space that an app has advised may be
          mergeable.  When it finds pages of identical content, it replaces
          the many instances by a single page with that content, so
          saving memory until one or another app needs to modify the content.
          Recommended for use with KVM, or with other duplicative applications.
          See Documentation/mm/ksm.rst for more information: KSM is inactive
          until a program has madvised that an area is MADV_MERGEABLE, and
          root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set).

Notice the 2 conditions - KSM isn't active "until a program has madvised that an area is MADV_MERGEABLE" and "root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set)". It is clear that any user could create or otherwise install a simple script to set the sysfs property "../ksm/run" to 1, but is sounds as though setting MADV_MERGEABLE has to be done by each application. How many applications use the madvise system call to set MADV_MERGEABLE?

Sorry, I just found out previous reply contain misinfomation.
Further investgate shows that Gemini got illusion. And the corrected investgate are demonstrated below.
There are indeed limited application that can make good use of this future, and I'm afraid that I was misleaded.
There are limited process that can make good use of this. And so far, only qemu and netdata stood out, and it indeed didn't representaive. Sorry for the inconvenience caused. Until futher evidence are on the table, I'll close the PR for now.
For anyone interested, I'll left the scan script below, it's been corrected and verify by myself. Now it should properly show how many process are able to benefit from KSM.
https://gist.github.com/xrh0905/fad545b44075e888be1db6de0e1cbd64